A typical enterprise computing environment includes multiple heterogeneous and distributed applications for accessing a variety of different systems covering different subject areas. For example, many enterprises such as businesses and the like have different systems to support customer billing, sales, accounting, inventory, ordering, procurement, technical support, field repairs, etc. Such different systems each generally have a dedicated application, e.g., a web application or a client server application, for accessing each of the different systems in an enterprise. Applications allowing users to access different systems are often incompatible with one another for a variety of reasons, particularly when, to begin with, such applications are not even part of the same enterprise.
In one common scenario, where an enterprise is the result of a merger or acquisition, the enterprise may have multiple unrelated systems for performing a single function. For example, the two companies joined by a merger may each have had their own systems for tracking repairs prior to the merger, and after the merger it may be impractical or difficult to combine the two systems. To take another example, an enterprise may have one system for provisioning or fulfilling new orders and another system for tracking repair requests, the two systems having been developed independently. However, it may often be the case that the same user, e.g., a customer, wishes to access multiple systems within an enterprise because multiple systems include data of interest to the user. Indeed, a customer's account information may be spread across multiple systems within the enterprise, e.g., repair, billing, provisioning, etc.
It is common for enterprises to have what is known as a portal, e.g., a web site, that is a single point of access, through which users both within and without the enterprise can access diverse applications and systems. Often, portals provide web pages with links to different applications. When a user selects such a link, the user is invited to log in to the selected application. In some cases, using a technique known as “account aggregation,” the user may be permitted to provide to the portal login information for various applications. The portal then stores the user's login information for each of the various applications, and maps this login information to the user's login information for the portal.
However, to provide login information to the portal concerning each of the various enterprise applications that the user may need to access, means first that the user have a login account for each enterprise application that the user will access, and second that the user is aware of the enterprise application that the user needs to access. In many cases, users will not have the time or knowledge to provide such information to a portal. Further, an enterprise may have multiple portals, e.g., due to a merger or the like as discussed above, but such multiple portals may be un-integrated and therefore data concerning user entitlements to various application features and functions included in one portal may not be included in a second portal.
In sum, because present portals are able to allow users to view certain sets of data only according to application-specific login information limited to the portal, present portals make it difficult, if not impossible, for users to access data of interest to them. In general, present portals do not allow users to quickly and efficiently access the data that they wish to see, and do not create an interface to various systems within an enterprise that renders transparent to the user of the fact that all of these different systems exist.